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AN INTERFACE BETWEEN FRONT-END SYSTEMS 
AND BACK-END SYSTEMS 

BACKGROUND OF THE INVENTION 

5 

The invention relates to performance of tasks by back-end systems. 

At present, organisations such as financial institutions devote considerable manpower 
to integration of front-end systems with legacy back-end systems. The back-end 
10 systems are often very efficient at carrying out intensive transaction processing tasks 
and it is desirable to minimise the impact of changes at the front-end on the back-end 
systems. It is also desirable to allow flexibility for modification of the back-end 
systems. 

It is an objective of the invention to provide an interface to reduce the manpower 
required for interfacing when changes are made to a front-end system. 

A related objective is to provide greater flexibility to organisations for modification of 
front-end systems. 

SUMMARY OF THE INVENTION 

The invention provides an interface for interfacing between front-end data processing 
systems and back-end data processing systems, the interface comprising an engine, a 
25 node layer comprising at least one node, and a utility layer comprising at least one 
utility, and in which: 

the engine comprises means for receiving a message containing a request from a 
front-end system for a transaction to be performed by a back-end system, and 
30 means for interpreting said message to select a relevant node for interfacing, 

each node represents business logic interf-aces to a back-end system. 
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each node exposes business logic capabilities to the engine; 

the engine comprises means for using the exposed node business logic 
capabilities to build a process map linking received request messages with nodes; 

each utility is coupled as a proxy to a back-end system, comprises means for 
receiving a transaction request from a node, for converting said request to a 
back-end system request, for receiving a response from the back-end system, and 
for routing a response to the requesting node, 

each node comprises means for routing a received response to the engine; and 

the engine comprises means for routing a response to the requesting front-end 
system. 
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to one embodiment, the et^e comprises means for dynamically maintaining the 
process map according to the exposed node business logic capabihttes. 

20 In one embodiment, the process map comprises a script file. 

to one embodiment, the process map comprises script messages, each message having a 
map associating incoming parameter names with standardised names. 

25 in one embodiment, each message of the process map specifies an associated node, a 
list of the parameters the node requires, and values which it re«.ms for a type of 

incoming message. 

in one embodiment, me utilities comprise means for mterfacing with the node layer 
30 according to a uniform interface model. 

in one embodimem, the engine comprises means for caUir^ a plurality of nodes for a 

transaction request. 
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In another embodiment, the engine comprises means for calling nodes in sequence, and 
for passing the output from a previous node to a next node. 

5 In one embodiment, the engine and each node comprise means for using a hashtable 
mapping keys to values for passing data and control to each other. 

In a further embodiment, the engine and the nodes each comprise means for using a 
hashtable for returning a result from a back-end system. 

In one embodiment, the engine comprises means for requesting a return value for a 
\ - transaction, and each node comprises means for defaulting to not passing a rem^ 

i if one is not so requested. 

% ,5 In one en*odiment, each of engine and each node con^rise an o^ecttatand^ 
3 from an object-oriented class. 

5 in one embodiment, each of the engine and each node comprises means for using a 

I hashtable which maps keys to values for passing data and control to each other, and the 

1 20 engine comprises means to, passing a hashtable as a parameter in an execute method, a 
commit method, and a roUback method of a node object. 

to another embodiment, the engine comprises means for activating a sequence of nodes 
for a transaction, and each node comprises means for performing a rollback rf a 

25 transaction fails. 

In one embodiment, the engine comprises an externally visible engme class, an object 
of which comprises means for instantiating: 
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processor object for instantiating said node objects; and 



a loader object for loading the process map. and for determining node objects 
associated with a received message. 
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to one embodiment, me engine comprises means for insmtoting a parser object for 
parsi,^ a reeved message, for placing extracted data in a hashtable, and for returmng 
the hashtable to the engine object. 

In one embodiment, the engine comprises a builder object comprising means for 
automaticany updating the process map according to capabilides exposed by node 

classes. 

In one embodiment, each node class comprises a method for remming a string to m 
engine indicating the node capabilities. 

According to ano^er embodiment, the inventron provides an interface for interfacing 
between front-end data processing systems and back-end data processing sys^n., the 
interface comprising an engine, a node layer comprising at least one node, and a utdtty 
layer comprising at least one utilily, and in which; 

the engine comprises means for receiving a message containing a request from a 
front-end system for a transaction to be performed by a back-end system, and 
means for interpreting said message to select a relevant node for interfacmg, 

each node represents business logic interfaces to a back-end system, 

each node exposes business logic capabilities to the engine; 

' me engine comprises means for using the exposed node business logic 

capabilities to build a process map linking received request messages with nodes; 

each utUity is coupled as a proxy to a back-end system, comprises means for 
;„ receiving a transaction request from a node, for converting said request to a 

back-end system request, for receiving a response from Are back-end system, and 
for routing a response to the requesting node. 
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each node comprises means for routing a received response to the engine, 

tiie engine comprises means for routing a response to the requesting front-end 

system, 

each of the engine and each node comprises an object instantiated from an 
object-oriented class, and 

each of the engine and each node comprises means for using a hashtable which 
maps keys to values for passing data and control to each other, and the engine 
comprises means for passing a hashtable as a parameter in an execute method, a 
commit method, and a rollback method of a node object. 

According to another aspect, the invention provides a method of interfacing between 
front-end data processing systems and back-end data processmg systems, the method 
being performed by an interface comprising an engine for communicating wrth the 
front-end systems and a utility layer for communicating with the back-end systems, the 
method comprising the steps of: 

the engine receiving from a front-end system a message incorporating a request 
for a transaction to be performed by a back end system but not indicating a 
particular back-end system suitable for the transaction, 

the engine using a process map to select one of a plurality of nodes in a node 
layer which may provide a suitable link to the back-end systems for tiie request, 
the process map linking message types to nodes according to exposed busmess 
logic capabilities of the nodes, 

the engine passing a request to the selected node, 

the selected node communicating with a utility with which it is associated to 
insfruct the utility to perform the transaction, receiving a response from the 
utility, and passing the response back to the node. 



the node passing the response back to the engine, and the engine passing the 
response back to the requesting front-end. 

In one embodiment: 

the engine dynamicaUy creates a node object according to parameters 
retrieved from the process map, 

the engine passes data from the received message to the created node, 
and 

data is passed between the node object and the engine by passing a 
hashtable linking keys with associated data. 

In one embodiment, the engine passes a hashtable as a parameter in an execute 
method, a commit method, and a rollback method, and the node rolls back accordmg 
to the rollback method if the transaction fails. 

In one embodiment, the process map is an XML script file. 
BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be more clearly understood from the following description of some 
embodiments thereof, given by way of example only with reference to the 
accompanying drawing in which:- 

Fig. 1 is a diagram iUustrating the architecture of an interface of the invention. 
DETAILED DESCRIPTION OF THE INVENTION 

Referring to Fig. 1, an interface 1 interfaces between sales order processing front end 
systems (not shown) and legacy back-end systems. The front end system may, for 
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■ example be a Web server aUowmg business-u^busmess sales. The latter are a sales 
. ..^^ .s^ n.^.. s..« l. X^e ..erfa. 1 — 
Lne 2, a node layer, and a utility layer. The node layer compnses a sales node 3 and 
rbmL node 4 The sales node 3 is coupled to a sales system utihty 5 and to a 
ZZ ysl utility 6. The billin, node . is coupled to a billin, utiti^ 7. T^s 
lls Jon is of tire Interfax 1 in ti>e process of handling transactions. T^e nodes 3 
and 4 are not stable, ttrey are dynamically created by tire engine 2 in real time. 

The engine is a processing unit tirat receives instnrctions on tasl. to be performed 
I! ssag«) and tire data needed to perform tire tas.. It contains no busmess-speaf^ 
rjc interprets tire message and activate tire appropriate node, to process tire tas.^ 
^engine 2^ and maintains a process map 15 tirat matches received messages v.tir 
the nodes that process that messages. 

, T^e nodes are business logic interfaces to bac.-«rd systems. Node classes e^ose tirdr 
capabilities in terms of business tas. to be completed and/or -sages ha^^e. T 
e^^osed information is used by tire engine 2 to build tire process map 15. Nodes may 
use any number of utility components. 

,„ The utilities directiy access badt end systems, l^ey may all l.ve " inte*^, 
hut are buUt on an interface model such tirat tireir implementation can chang^ wrtir ut 
!;l^ng tire caUer. Hov^ever, if a change to tire interface is re,uired. rt rs stiU rso a.d 
Lm tirt originator of tire tasU at ti. node level. Bach utiU. serves as^aprox 
back end system, providing a standardised language an mvocation mettrod for tire 

« nl Each utiht^ is an object, and each node class is coded wrth tire attnbutes of 
associated utilities. 

h, tire example of Fig. 1, a sales order comes in ftom tire Web to tire -Sine 2^ 
engine 2 looks in tire process map 15 and finds tirat tire sales and Ca-s " 
30 i.ltiatedtocreatetirenodes3and4. ^ P^es the order menage and rel^^t^. 
to tire respective nodes. The sales node 3 contains tire busmess logrc tirat rt must make 
particular calls into ti. sales system 10 and tire shipping system 11, whrch rt does by 
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way of the utUities 5 and 6. The billing node 4 contains logic that it needs to make a 
call into the biUing system 12, which it does by way of the billing utility 7. 

This allows for all business logic to be contained in the process map 15 and the node 
classes If a new process needs to occur, simply writing a new node class and addmg it 
to the process map 15 will integrate it into the system If a new back-end sales system is 
purchased, changes can be made to just the sales system utility to access it, thus limiting 
changes and decreasing the chance of bugs in the system However, if the utility 
interface is insufficient, the change can still be isolated at the node level. 

Hash tables are used for passing of messages and data, and the following summarises 
operation of the interface 1 . 

1 . A message is received at the interface 1 . 
2 Nodes are created to handle the message. 

3. The engine takes the details of the message and puts them in a hashtable. 

4. This hashtable is passed to a node. 

5 . The node retrieves data that it requires from the hashtable. 

6. The node accesses one or more utility objects to achieve its objective. 

7 The node can insert data into the hashtable. 

8 Steps 4 & 5 are repeated for each node that handles the message. 

9 Data to be returned to the request originator is retrieved from the hashtable and sent 
■ back over a message bus. This is controlled by a RETURN MESSAGE description 

in the process map 15. Thus, the caller only receives the requested information, 
thus minimising used bandwidth on the message bus. 

In more detail, the engine 2 uses the process map 15 to determine which nodes need to 
be created when a message (such as a SALESORDER) arrives. The message could be 
in any format. Hie engine 2 interprets it and places it in a standard format for the 
nodes The engine 2 then creates the node objects based on their class and location and 
calls them with the message and the parameters in the standardised format. As the 
engine 2 calls each of the nodes in order, it accepts the output from the previous node 
and passes it to the next node. This allows for resolution of processing dependencies. 
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The foUowing object-orienKd dass« comprise *e engine 2. 

. ■ Thi. is an externally visible class that instantiates and coordinates 
Engine. Ttas .s an extern y ^^^^ This allows the 

access to EngineProcessor and EngmeScriptL 
engine 2 to he scalable. Multiple EngineProcessors could be runmng 

time. 

, „r This class finds out which nodes should be executed tor a 
EngineProcessor. This class n ,„rt „akes the appropriate caUs. 

particular message and then loads those classes and makes the app 
. ■ .criotLoader This loads the process map XML confls^rauon script. 

-dthescriptwhiletheen.ne2isproc«sing. This 
I^LandaUowstorcustomisationwhileprocessingconnnues. 

' ^ Thk is for parsing an incoming message. This class is 

EngineMessageP^^ - ^-J^ Ljec. so the message formats can change 
abstracted away from me ungmc j 
without affecting the rest of the code. 

• . •M.r a class which updates the process map script XML file 
,0 EngineScnptBurlder rs a class wlu P maintenance and 

with the capabilities of a new node. Thxs class allow 
deployment, since the modifications needed to add a new node 
can be done by the computer. 

25 The foUowing are the node classes. 

i viQtiriip this sDecial new node type, 

2 wiU not need to change to handle Ous spe ^^^^^^^ 

performance and scalabUity. 
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MessageData - Tins class maintains all the nodes associated with a particular 
message. 

following describes operation of the interface 1 in more detail: 



Start Up : 

The engine 2 is started on the system. 

,0 Tl>e engine creates an EngineScripioader object which parses the process map XML 
file Parsing of the XML file only needs to be done once per Engme object 
initialisation, for tmproved performance. The EngineScriptLoader object uses me 
information in the XML file to create a MessageData object for each message me 

engine 2 can handle. 

" The EngineScriptLoader object creates a NodeDau entry in each MessageData object 
for each node that wants to execute when the message is received. 

Tlie MessageData o^ects sort their NodeData entries based upon descriptions of their 
20 inputs and outputs and any designated order attributes as dedared irt the XML file 15 
with the end result titat it knows the proper order in which to call the nodes. Tins 
allows for smaU nodes to be plugged mto the system to solve larger tasks m 
combination. 

25 Message Processing: 

A message is passed to the Engine class. The Engine class creates an mstance of an 
En^neMessageParser. passing it the message to process. The EngineMessagePars„ 
extracts tire relevant information ftom ttie message, placing it in a hashtable, and 
retitming it to the Engine, lire Engine class creates an instance of an EngineProcessor 
30 Object, passing it a reference to tire En^eScriptLoader and tire hashtable result ftom 
flie EngineMessageParser. The En^eProcessor rec^ests Ute MessageData object 
corresponding to a.e message received ftom the EngineScriptLoader. The 
EngineProcessor begins making caUs into fl,e NodeData objects stored m Uie 
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MessageDa,a object passing ±e hashtable ftom me message. Each node can mod.^, 
I. o delete values .otn tMs hashtable as it passes between nodes. T.US Otey cat. 
constructed to rely on a predecessor. If a node should fail, all pre^ding nodes are t..d 
rollback Whatever tbey have done as a resuU of processing. Otherwrse. whenj 



changes. 
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Finauy. if a tetum message is listed in the MessageData object, its description is 
retrieved and the message is constn^cted and sent bac. to the ori^nator of the request. 

?;:C-t modified by hand, by a custom editor or automaacally. Automate 
script modification is accomplished by a call to the engine passing in a new node. The 
new node contains a method which wiU remm XML descrtbing *e messages the node 
Lie to process, the inputs it expects, and the outputs tt produces. ll.e En^ne .ea^ 
an EngmeScriptBuilder object which automatically merges this informatron v.* the 
l^TxML Lipt. The Engine then issues a request to the EngineScriptLoader to 
reload its information from the newly changed file. 



20 Node Implementation: 

The nodes are required to implement the foUowing methods: 

* This method is used to verify tiiat all necessary 

* data to complete an operation is available. 



" plblic boolean Execute (String msk. String tasMD. Hashtable values)throws Exception; 



* This method returns an XML string that describes tiie tasks 
30 * tills Node can perform and tiie parameters it uses. 
*/ 

public String TasksProvidedO flirows Exception; 
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* This method is either used to do the execution of the task, 

* or to commit the task with the supplied tasklD. 

5 plic void CommitCStrir^g task. Strir^g taskID, Hashtable values); 
* This method roUs back a particular operation. 



,0 *plbUc void RoUbackCStrirtg task, String tasklD. Hashtable values); 

This interface based ac^ss to me nodes allows the en^e to ^"^^^^ 
standard way to any system it is integrated wim. allowmg new nodes to be added 
without requiring changes to the engine. 

' ' The Mowing is a sample of a process map XML ffle for a purchase request. 

<?xml version=" 1 .0"?> 
<MESSAGES> 
20 <ONLINEPURCHASE> 

<DDMAP> 
<MSG ddname="message"/> 
<NAME ddname="customerName"/> 
<ADDR ddname="customerAddressV> 
25 <RETVAL ddname="RetumValue"/> 

</DDMAP> 
<NODES> 

<SALESNODE class="Sales" location="file:F:\" order="l > 
<PARAMETERS> 
30 <message /> 



customerName / 



> 



<RetumValue iii="false" out="true"/> 
</PARAMETERS> 
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</SALESNODE> _ 
<BILLINGNODE class="Billing" location="file:F:\\" order- 

<PARAMETERS> 
<message /> 
5 <custonierName /> 
<custonier Address /> 

<RetumValueiii="true" out="trueV> 

</PARAMETERS> 
</BILLrNfGNODE> 
10 <SHIPPINGNODE class=" Shipping" location="file:F:\\" > 

<PARAMETERS> 
<message in="true" out="falseV> 
<customerName /> 
<customer Address /> 
15 <RetumValue in="false" out="trueV> 

</PARAMETERS> 
</SHIPPINGNODE> 

</NODES> 

<RETURNMESSAGEname="RetumFromOnUnePurchase > 

20 <RETVAL /> 

</RETURNrMESSAGE> 

</ONLINEPURCHASE> 

<ONLINERETURN> 

<DDMAP> 
25 <MSG ddname="message"/> 

</DDMAP> 

^<SER^CENODE class="CustomerService" location="file:F:\" order="r> 
<PARAMETERS> 

30 <message /> 

<ReturnValuein="false" out="trueV> 

</PARAMETERS> 
</SERVICENODE> 
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</NODES> 



</ONLINERETURN> 



< 



/MESSAGES> 



AS set out above, the XML script is organi^d into messages. Within each message ts a 
DDMap which desctihes the incoming parameter names and associates them to 
standardised names. For example, in the ONLINEPURCHASE message toe is a 
parameter "MSG". When passing this parameter to the nodes it should be called 
"message". This is to help standardise node interfacing. 

There is a NODE section for each message which contains the nodes that should be 
called for the message. Under each node entry is a hst of the parameters the node 
requires and mose values that is remms. If there is no "in" or "out" designator, the 
parameter is assumed to "in" only. These are the values used by Are 
EngineScriptLoader about to decide the execution order of the nodes. The map 15 also 
designate the node order. 

Within each message section, there may be a RETURNMESSAGE designator. Tbis is 
the message that should be constructed and returned to the originator of the request. 
The "name" designator is the name of the message to remm. The sub-entries are the 
names of the remm values to puU out of the hashtable of values that were passed to the 
nodes during processing. These wiU be bundled up into the return message. 

Regarding the hashtables. they are used to store and retrieve information passed 
between nodes as well as the en^ne by giving them field names. For example 
"CustomerFirstName" might be mapped to "David" in the table. One node could 
retrieve it from a database and store it under "CustomerFirstName". and a subsequent 
node which needs that information could go the hashtable and request the value of 
"CustomerFirstName" and be provided "David". A hashtable is passed as a parameter 
in the Execute, Commit, and RoUback methods of the node object. The hashtables 
essentially map a key to a value. Keys in a hashtable are unique. 
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Values that are placed in the hashtable are "message" and "RetumValue". "message- 
might contain something like "Please send via 2nd day air." which could be retrieved by 
the node so it could store that in with the customer's order for special handling. 
"RetumValue" would contain the result of the operations. For example, after aU the 
nodes process, one of the nodes might have placed "Total shipping cost is $24.00" 
under "RetumValue" in the hashtable, so that the engine can send that back to the front 
end, allowing it to display the cost to the user. In the RETURNMESSAGE section, it 
would have to designate "RetumValue" as being of interest to the front end, so that it 
would return that value to the front end. 

It will be appreciated that the invention provides excellent versatility in choice and 
configuration of front-end and back-end systems. Very little programming is required 
for configuration changes, partioilarly as the EngineScriptBuilder object automatically 
maintains the process map. Another advantage is versatility in the nature of requests 
and responses by virtue of use of hashtables as described. Also, the reply mechamsm 
provides for a low message bus bandwidth requirement. Another benefit of the 
architecture is the fact that the interface 1 achieves full transactional capability, (i.e. 
commit, rollback). 
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It will also be appreciated that the manner in which the interface 1 operates leads to 
excellent data integrity. The invention also removes dependencies between back end 
systems in a very effective manner. 

The invention is not limited to the embodiments described but may be varied in 

and ^^^1^- 

constmction 



